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Section  I 

A 

Introduction .  The  purpose  of  this  assessment  is  to  determine  the  work 
necessary  to  merge  the  ADAM  III  functionality  into  CMOS- ->  This  final 
report  is  the  culmination  of  the  previous  version  and  further  study. 

Summary.  The  general  strategy  "-for  this  study  vwas  to  examine  the 
requirements  contained  in  the  Draft  Functional  Requirements  Document  and 
determine  their  impact  in  each  of  six  system  design  element  categories. 

Five  steps  were  needed  to  complete  this  study.  In  order  of  occurrence, 
they  were.’-fl)  to  explain  the  processes  at  work  i^n.  ADAM  III,  \2 )  to 
identify  the  system  design  element  categories;  .‘(3)  ^to  visualize  the 
incorporation  of  ADAM  III  requirements  into  CMOS;  .('4 )  to  record  each 
instance,'  and  (5)  to  total  the  counts  for  each  category.  Sizing  the  scope 
of  the  CMOS  ADAM  III  merger  should  be  tempered  by  the  presence  of 
mitigating  factors.  These  include:  -{l )  evolutionary  requirements 
definition;  Appendix  A  contains  the  version  of  the  Draft  Functional 
Requirements  Document'  used";  (2 )  documentation  constraints ;  {3 ) 
requirements  integration  into  the  conceptual  model  of  CMOS/  -(4)  no 
measurement  of  process^  complexity^  significant  complexity  is  unquantified 
for  28  requirements;  (>5)  inability  to  allocate  all  requirements  to 
categories;  and  { 6 )  lack  of  interchangeability  between  CMOS  ad  hoc  queries 
and  ADAM  III  preformatted  queries.  ? ,■  u  .  ,,lyr  p  \  '  •  Lor<’Z'f’>e*  h?  v..  v.'/A 

w  r  /  --n  s )  ~  ^ 1  *  _  v.  *  '  / 

Conclusion .  The  additional  work  for  merging  the  ADAM  III  requirements  )  '  J‘  AA" 
into  CMOS  is  shown  in  the  table  below.  V 


MENU  FULL  HHT  LOCAL  DATA  TRANSFERS  DATA 

OPTIONS  SCREENS  SCREENS  REPORTS  MESSAGES  FIELDS 

<5  5-26  >26 

TOTAL  63  145  186  52  60  38  14  2 
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Section  II 
Results . 

A.  Overview. 

Purpose.  As  stated  earlier,  the  purpose  of  this  assessment  is  to 
determine  the  work  necessary  to  merge  ADAM  Ill's  functionality  into 
CMOS . 

Strategy.  The  Draft  Functional  Requirements  Document  prepared  by 
representatives  of  the  CMOS  Program  Office  and  SAIC  after  trips  to  HQ 
MAC  Scott  AFB,  IL  (8-12  JAN  90)  and  the  436  APS  Dover  AFB,  DE  (26  FEB 
to  2  MAR  90)  provides  the  basis  for  this  study.  The  general  strategy 
for  this  study  was  to  examine  the  requirements  contained  in  the  Draft 
Functional  Requirements  Document  and  determine  their  impact  in  each  of 
six  system  design  element  categories. 

Des^-  i  ration  of  Approach .  The  five  steps  used  in  this  study  are  as 
foj  : 

1.  v.  .  d-  the  processes  at  work  in  ADAM  III  and  the  information 
available.  o  its  users.  This  was  done  by  observing  aerial  port 
operations,  talking  with  port  and  HQ  MAC  personnel,  and  examining  the 
ADAM  III  User's  Manual  (draft)  and  record  layouts. 

2.  Identify  six  categories  of  system  design  elements  for  use  in 
quantifying  the  impact  of  the  requirements.  The  categories  are:  Menu 
Options,  Full  Screens,  Hand  Held  Terminal  Screens,  Local  Reports, 
Data  Transfers  and  Messages,  and  Data  Fields.  A  Menu  Option  is 
defined  as  an  additional  line  on  an  input  screen  that  represents  a 
function  available  for  selection.  A  Full  Screen  is  an  entire  screen 
needed  either  to  facilitate  data  input  or  to  present  a  menu  of 
functions.  A  Hand  Held  Terminal  (HHT)  Screen  represents  the  HHT's 
equivalent  to  the  Full  Screen.  The  category  of  Local  Reports  includes 
preformatted  data  base  queries,  managerial  reports,  and  reports  that 
aid  day-to-day  operations,  including  forms  and  movement  documents.  The 
Data  Transfers  and  Messages  category  was  established  to  track  the 
number  of  different  messages  or  notices  that  flow  port  to  port,  port 
to  HQs',  and  HQ  MAC  to  external  systems.  The  Data  Fields  category 
represents  the  estimated  additional  number  of  data  fields  necessary  to 
satisfy  the  requirement. 

3.  Visualize  the  incorporation  of  the  ADAM  III  requirements  into  CMOS 
via  the  six  categories.  ,  ■ 

4.  Record  each  instance  where  a  new  design  element  was  needed  to 
satisfy  the  requirement  without  repeating  the  count  for  the  same 
requirement  elements.  Generally,  additional  functions  were  counted  as 
needing  at  least  one  menu  option  and  at  least  one  full  input  screen. 
These  were  adjusted  for  the  amount  of  data  needed  or  for  the  format  of 
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particular  reporting  functions.  When  an  estimate  of  the  equivalent 
number  of  HHT  screens  was  needed  a  ratio  of  one  full  screen  to  six  HHT 
screens  was  applied.  This  ratio  was  derived  as  follows:  A  typical 
full  size  input  screen  contains  space  for  1920  characters  (80  X  23 
characters).  The  HHT  input  screen  contains  space  for  80  characters  (4 
X  20  characters).  Since  approximately  half  of  a  full-sized  input 
screen  is  blank  and  the  space  devoted  to  prompts  could  be  reduced  by 
half/  the  space  utilized  for  a  full  screen  can  be  estimated  at  480 
characters.  Dividing  480  by  80  (the  space  available  on  an  HHT  screen) 
provides  the  ratio  of  1:6.  Six  represents  an  average  that  is 
designed  to  produce  a  close  estimate  of  the  total  number  of  HHT 
screens  required.  Therefore,  it  may  appear  high  or  low  as  applied  to 
each  instance.  One  preformatted  query,  managerial  report,  or 
operational  report  resulted  in  one  count  for  local  reports .  The 
relationships  between  ADAM  III  and  overseas  ACA,  MATCU,  CONUS  ACA, 
MAC  HOST/TRAIS/MACA,  and  DAMMS-R  are  viewed  strictly  as 
data  transfers,  even  though  gray  areas  exist  where  the  overseas  ACA 
and  the  MATCU  use  ADAM  III  data.  In  these  cases,  updates  and  queries 
are  counted  as  a  data  transfer.  The  estimated  number  of  data  fields 
falls  into  one  of  three  categories  -  less  than  five  (<  5),  five  to  26 
(5  -  26),  and  more  than  26  (>  26). 

5.  Total  the  counts  for  each  category.  For  the  data  fields,  a  count 
for  each  range  was  used  instead  of  a  discrete  sum  of  data  fields. 

Qualifications .  A  number  of  mitigating  factors  affected  the  results 
of  this  study.  These  factors  should  be  incorporated  into  the 
simplified  sizing  counts  to  form  a  more  accurate  basis  for  determining 
the  scope  of  the  MAC  CMOS  merger. 

1.  Requirements  definition.  The  requirements  considered  for  this 
study  were  limited  to  those  identified  in  the  Draft  Functional 
Requirements  Document.  This  document  is  currently  under  review  by 
CMOS  PMO  and  HQ  MAC  TR/SC  staffs.  Requirements  definition  is 
nearing  completion.  Since  this  is  the  final  version  of  the  level  of 
effort  assessment,  we  used  the  known  requirements  to  size  the  task.  A 
copy  of  the  version  used  for  this  study  is  at  Appendix  A.  Each 
estimate  for  a  design  element  is  based  on  the  amount  of  information 
available  about  the  requirement.  Fach  estimate  can  be  expected  to 
deviate  from  the  future,  .actual  count  by  some  amount.  The  degree  of 
information  available  about  the  requirement  will  influence  the 
variance  between  the  actual  and  estimated  counts.  This  is 
particularly  relevant  for  reports  generation  and  exchange  between  HQs 
and  ports.  There  is  a  high  probability  that  MAC'S  final  determination 
of  reporting  requirements  will  deviate  significantly  from  the 
estimates,  because  these  reports  are  currently  undefined,  pending 
analysis  by  HQ  MAC. 
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2.  Documentation  constraints.  The  initial  strategy  for  accomplishing 
this  task  was  replaced  with  a  second,  because  the  needed  information 
was  not  found  in  existing  documentation.  The  strategy  for  this  final 
report  is  the  same  as  the  second,  but  an  updated  version  of  the 
requirements  was  used. 

a)  The  initial  strategy  for  this  task  was  to  isolate  the  ADAM  III 
requirements  not  covered  in  CMOS,  compare  these  to  the  CMOS  design 
relationship  of  system  capability  >  data  entity  >  data  fields,  and 
thereby  establish  the  design  elements  needed  to  incorporate  ADAM  III 
requirements  into  CMOS.  However,  this  effort  revealed  shortcomings 
in  the  CMOS  and  ADAM  III  documentation.  For  CMOS,  CSC  I 
documentation  does  not  map  all  of  the  system  capabilities  to  data 
entities.  This  prevented  the  construction  of  the  relationship.  At 
this  stage  of  development,  CMOS  documentation  does  not  contain  the 
level  of  detail  needed  to  make  comparisons.  From  the  ADAM  III 
perspective,  life  cycle  documentation  has  not  kept  pace  with  system 
advances.  The  documentation  available  may  not  completely  and 
accurately  depict  how  ADAM  III  has  evolved. 

b)  The  second  strategy  employed  the  first  draft  of  the  Functional 
Requirements  Document  as  the  basis  for  defining  ADAM  III 
requirements  beyond  the  scope  of  CMOS. 

c)  The  third  strategy  employed  the  Draft  Functional  Requirements 
Document  as  the  basis  for  defining  ADAM  III  requirements  beyond  the 
scope  of  CMOS. 

3 .  Requirements  integration .  Our  analysis  does  not  universally 
integrate  ADAM  III  requirements  into  the  conceptual  design  of  CMOS. 
Because  of  complexity  and  command  dependency,  certain  aerial  port 
procedures  do  not  lend  themselves  to  integration.  Over/short  shipment 
handling  and  HOST (HQ  MAC)  -  MINIS  (port)  reporting  are  two  examples. 
Conversely,  aerial  ports  employ  standard  transportation  practices, 
with  minor  variations,  and  these  are  treated  as  a  superset  of  CMOS 
procedures.  The  relationship  between  the  MAC  unique  areas,  MAC 
procedures  that  are  an  extension  of  CMOS,  and  CMOS  is  shown  in 
Attachment  1 . 

4.  Lack  of  complexity  measurement.  The  method  of  measuring  this 
level  of  effort  by  counting  micro  level  design  elements,  such  as 
screens  and  interfaces,  fails  to  measure  the  complexity  inherent  in 
the  processes  behind  those  elements.  Since  procedural  steps  and  other 
complexities  could  not  be  measured,  the  task  has  been  over  simplified, 
and  the  degree  of  complexity  for  28  requirements  is  unquantified. 

5.  Requirement  allocation.  Not  every  requirement  could  be  allocated 
among  the  categories.  For  example,  CMOS  terminals  for  NAFs,  ALDs,  and 
MATCUs  are  an  architectural  matter  beyond  the  scope  of  this  task. 
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6 .  Ad  hoc  versus  pref  ormatted  queries .  The  CMOS  ad  hoc  query 
capability  cannot  be  considered  a  direct  substitute  for  the 
pref ormatted  queries  required  by  ADAM  III.  Ad  hoc  queries  generally 
must  be  constructed  each  time  they  are  issued;  this  makes  them 
inefficient  as  aids  in  performing  routine,  predictable  operations. 
Therefore,  some  of  ADAM  Ill's  preformatted  query  requirements  are  not 
viewed  as  being  met  by  CMOS  and  have  been  included  in  this  study. 


B.  Draft  Requirements  Definition  Document  References  and  Data. 

This  subsection  contains  the  Draft  Functional  Requirements  Document 
headings  and  paragraph  numbers  as  they  appear  in  the  attached  version. 
The  individual  requirements  have  been  broken  out  to  allow  the  elements 
to  be  counted.  The  tables  relate  the  requirements  to  the  design 
element  categories  and  provide  the  counts.  An  *  next  to  a  requirement 
denotes  complexity  that  could  not  be  quantified. 

1 . 1  System  Functions . 

1.1.1  Port  hold  time. 

a.  Track  and  color  code  (red/yellow/green)  cargo  status  based  on 
port  hold  time. 

b.  Calculate  port  hold  time  from  actual  aircraft  or  truck 

arrival  time.  Port  hold  time  begins  with  cargo  receipt  time  which 
is  called  System  Entry  Time  (SET). 

c.  End  port  hold  time  at  actual  aircraft  or  truck  departure 

time . 

d.  End  port  hold  time  when  inbound  cargo  is  in-checked  and 

identified  for  outbound  surface  movement. 

e.  Discontinue  port  held  time  accrual  while  cargo  is  frustrated. 


MENU 

FULL 

HHT 

LOCAL 

DATA  TRANSFERS 

DATA 

OPTIONS 

SCREENS 

SCREENS 

REPORTS 

MESSAGES 

FIELD? 

a* 

0 

0 

0 

0 

0 

<  5 

b. 

0 

0 

0 

0 

0 

<  5 

c . 

0 

0 

0 

0 

0 

<  5 

d . 

0 

0 

0 

0 

0 

<  5 

e . 

0 

0 

0 

0 

0 

<  5 

1.1.2  Cargo  tracking. 

a.  Track  the  status  of  loose  cargo  for  all  airlift  cargo  using  the 
following  status  codes: 

(.’)  7-s.DV  -  Advance  ( ATCMD  submitted  but  cargo  has  not  arrived.) 


(2)  SEN  -  Sentinel  (Cargo  was  deleted  but  the  record  has  not 
been  purged  from  the  data  base.) 

(3)  INC  -  In-check  (Cargo  is  on-hand  but  not  movement  ready.) 

(4)  PRO  -  Processed  (Cargo  is  on-hand,  movement  ready,  and 
awaiting  lift.) 

(5)  PLT  -  Palletized  (Cargo  is  on  a  pallet,  movement  ready, 
and  awaiting  lift.) 

(6)  PLP  -  Palletized  Load  Planned  (Cargo  is  on  an  air  load 
planned  pallet.) 

(7)  MNL  -  Manifested  Loose  (Loose  cargo  that  is  air  load 
planned. ) 

(8)  LFT  -  Lifted  (Loose  cargo  which  has  departed.) 

(9)  PLL  -  Palletized  Lifted  (Palletized  cargo  which  has 
departed. ) 

(10)  AIB  -  Air  Inbound  (Cargo  scheduled  to  arrive  on  an  inbound 
mission. ) 

(11)  ARP  -  Air  Receipted  Palletized  (Palletized  cargo  arrived 
by  air  but  not  movement  ready. ) 

(12)  AIR  -  Air  Inbound  Receipted  (Loose  cargo  arrived  by  air 
but  not  movement  ready. ) 

(13)  LDP  -  Loud  Planned  (Loose  cargo  load  planned  for  surface.) 


b.  Track  the  status  of  containerized  cargo  (pallets,  MILVANS,  and 
other  containers)  for  all  airlift  cargo  using  the  following  status 
codes : 


(1) 

Sen 

(2) 

BIP 

(3) 

PAR 

(4) 

CAP 

(5) 

LDP 

(6) 

MAN 

(7) 

LFT 

(8) 

AIB 

(9) 

AIR 

(10) 

AIC 

(11) 

ABD 

MENU 

OPTIONS 

a .  0 

b.  0 


Sentinel 

Build-In-Progress 
Partial  Pallet 
Complete  Pallet 
Load  planned 
Manifested 
Lifted 

Air-In-Bound 

AIB-Received 

AIB-INC 

AIB-Breakdown 


FULL 

HHT 

LOCAL 

DATA  TRANSFERS 

DATA 

SCREENS 

SCREENS 

REPORTS 

MESSAGES 

FIELDS 

0 

0 

0 

0 

<  5 

0 

0 

0 

0 

<  5 
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1.1.3  Frustrated  cargo  tracking. 


a.  Track  the  status  of  frustrated  loose  cargo  and  containers 
(pallets,  MILVANS,  and  other  containers)  for  all  airlift  cargo  using 
the  following  status  codes: 


(1)  FRD  -  Requires  diplomatic  clearance. 

(2)  FR1  -  Incomplete  or  improper  documentation,  including 
packing,  labeling  or  marking  that  cannot  be  corrected 
at  time  of  in-check. 

(3)  FR2  -  Receipt  of  damaged  shipments. 

(4)  FR3  -  Request  from  ACAs/MATCOs/MATCUs  to  hold, 
divert,  or  otherwise  remove  a  shipment  from  the 
airlift  system. 

(5)  FR4  -  Request  from  US  Customs  to  hold,  divert,  or 
otherwise  remove  (confiscate)  a  shipment  from  the 
airlift  system. 

(6)  FR5  -  Receipt  of  suspected  pilfered  shipments. 

(7)  FR6  -  Shipments  awaiting  air  clearance  either  at 
origin  or  destination  station.  (Example:  A  shipment 
of  class  A  explosives  may  be  frustrated  at  the  APOE 
due  to  limited  storage  capacity  at  the  APOD. ) 

(8)  FR7  -  Shipments  received  and  in-checked/processed  but 
cannot  be  located  within  the  terminal  complex;  i.e., 
shipments  overshipped,  incorrect  entries  into  the 
data  base,  stolen/lost  shipments  and  items  not 
located  during  terminal  inventories.  (These  items 
must  have  DISCON,  DISREP  or  tracer  actions  as 
appropriate  initiated.) 

( 9 )  FR8  -  Reserved . 

(10)  FR9  - 


Reserved . 


(11)  FRE  -  This  frustration  code  is  automatically  assigned 
by  the  system  if  documentation  errors  were  found 
during  Air  Inbound  processing. 


— 

MENU 

FULL 
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DATA  | 

OPTIONS 

SCREENS 

SCREENS 
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MESSAGES 

FIELDS  | 

a .  0 

0 

0 

0 

0 

<  5  j 

1.1.4  Edit  bay  locati  ,a  and  mode  code . 

a.  Change  cargo  bay  locations  and  MILSTAMP  mode  codes  for  cargo  and 
containers  in  the  backlog  using  a  PC  workstation  or  hand-held 
terminal . 


MENU  '  .L  HHT  LOCAL  DATA  TRANSFERS  DATA 

OPTIONS  SCREENS  SCREENS  REPORTS  MESSAGES  FIELDS 
a.  2  0  00  00 


1.1.5  TCN  edit  check. 

1 . 1 . 5 . 1  Entry  error . 

a.  Require  the  operator  to  verify  the  TCN  when  an  exact  match  is  not 
found,  but  there  is  a  TCN  where  all  the  characters  are  identical 
except  two. 


MENU  FULL  HHT  LOCAL  DATA  TRANSFERS  DATA 

OPTIONS  SCREENS  SCREENS  REPORTS  MESSAGES  FIELDS 
a .  0  1  6  0  0  0 


1. 1.5.2  Add  TCN. 

a.  Require  the  operator  to  add  a  new  TCN  when  an  exact  match  is  not 
found  and  the  closest  TCN  has  three  or  more  different  characters. 


MENU  FULL  HHT  LOCAL  DATA  TRANSFERS  DATA 

OPTIONS  SCREENS  SCREENS  REPORTS  MESSAGES  FIELDS 
a.  1  0  00  00 


1 . 1 . 5 . 3  Edit  TCN . 

a.  Allow  the  operator  to  correct  a  TCN  that  he  perceives  was 
erroneously  entered  at  the  origination  station. 


MENU  FULL  HHT  LOCAL  DATA  TRANSFERS  DATA 

OPTIONS  SCREENS  SCREENS  REPORTS  MESSAGES  FIELDS 
a.  1  0  00  00 


1.1.6  Inventory. 

1.1. 6.1  Manual  inventory. 

a.  Produce  a  hard  copy  list  of  cargo  on-hand,  sorted  by  bay  location. 

b.  Resolve  discrepancies  between  the  hard  copy  list  and  the  cargo  by 
entering  corrections  at  the  PC  workstation. 


MENU 

FULL 

HHT 

-jOCAL 

DATA  TRANSFERS 

DATA 

OPTIONS 

SCREENS 

SCREENS 
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MESSAGES 

field: 

1 

1 

0 

1 

0 

0 

1 

1 

0 

0 

0 

0 

1.1. 6. 2  Hand-held  terminal  inventory. 


a.  Scan  or  enter  by  key  stroke  TCN  information  for  cargo  on-hand  by 
bay  location. 

b.  Compare  with  prepositioned  information  and  identify  discrepancies 

c.  Notify  the  appropriate  work  center  to  move  cargo  found  in  the 
wrong  bay  location. 


MENU 

FULL 

HHT 

LOCAL 

DATA  TRANSFERS 

DATa 

OPTIONS 

SCREENS 

SCREENS 

REPORTS 

MESSAGES 

FIELDS 

a. 

1 

1 

6 

0  . 

0 

0 

0 

0 

0 

0 

0 

0 

c. 

0 

0 

0 

1 

0 

<5 

1 . 1 . 6 . 3  Inventory  over/short  procedures . 

a.  Check  and  clear  overages  found  during  inventory  with  the  short 
shipment  register. 

b.  Create  TCMD  data  for  overages  not  reconciled  with  the  short 
shipment  register. 

c.  Provide  this  capability  to  the  ATSA  and  air  freight  work  centers. 

d.  Identify  shortages  to  the  system  manager  for  resolution. 


MENU 

FULL 

HHT 

LOCAL 

DATA  TRANSFERS 

DATA 

OPTIONS 

SCREENS 

SCREENS 
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MESSAGES 

FIELDS 

*a . 

0 

0 

0 

0 

0 

0 

b. 

1 

1 

6 

0 

0 

0 

*c. 

0 

0  •' 

0 

0 

0 

0 

d. 

1 

1 

0 

1 

0 

<5 

1 . 1 . 6 . 4  Inventory  timing  and  documentation . 

a.  Prompt  the  operator  to  perform  the  inventory  based  on  a  user 
defined  time  criterion. 

b.  Document  the  date,  time  and  results  for  each  inventory  performed. 


MENU 

OPTIONS 

a.  0 

b.  0 


FULL 

SCREENS 

1 

0 


HHT  LOCAL  DATA  TRANSFERS  DATA 
SCREENS  REPORTS  MESSAGES  FIELDS 
0  0  0  <  5 

0  0  0  <  5 


1.1.7  Forms  production . 

a.  Produce  bar-coded  Military  Shipping  Labels  and  Pallet  Identifiers, 
and  Special  Handling  Data/Certification. 


MENU  FULL  HHT  LOCAL  DATA  TRANSFERS  DATA 

OPTIONS  SCREENS  SCREENS  REPORTS  MESSAGES  FIELDS 
1  1  0  0  0  0 


1.1.8  Consignee  information . 

a.  Validate  shipper  authenticity. 

b.  Determine  probable  bay  location  and  onward  movement  mode. 

c.  Reoriginate  intransit  cargo. 

d.  Allow  the  system  manager  and  ATSA  to  maintain  and  update  consignee 
information . 


MENU 

OPTIONS 

0 

0 

0 

0 


FULL 

SCREENS 

0 

0 

0 

0 


LOCAL  DATA  TRANSFERS  DATA 


SCREENS  REPORTS 


MESSAGES  FIELDS 
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1.1.9  Workload  reporting . 


a.  Capture  and  report  aerial  port  workload  data  to  complete  blocks 
II,  III,  B,  C,  D,  E,  IV,  and  V  of  the  RCS:MAC-TRX(M&Q)7107  report. 

b.  Generate  automatically  monthly,  quarterly,  at  user  defined 
intervals,  or  as  an  option  of  the  Reports  Processing  Menu. 


MENU 

FULL 

HHT 

LOCAL 

DATA  TRANSFERS 

DATA 

OPTIONS 

SCREENS 

SCREENS 

REPORTS 

MESSAGES 

FIELDS 

a  ♦ 

1 

1 

0 

0 

0 

>26 

b. 

0 

0 

0 

0 

0 

<  5 

1 . 2  External  Interfaces . 

1.2.1  CMOS  to  MAC  HOST  cargo  status  update. 

a.  Transmit  electronically  the  transaction  records  listed  below  over 
the  CMOS  to  HQ  MAC  HOST  interface: 

(1)  -  420  Additions  to  the  TCMD  record 

(2)  -  430  Changes  to  the  TCMD  record 

(3)  -  440  Deletions  to  the  TCMD  record 

(4)  -  425  Additions  to  the  pallet  header 

(5)  -  435  Changes  to  the  pallet  header 

(6)  -  445  Deletions  to  the  pallet  header 

b.  Create  and  send  these  transactions  at  the  time  of  each  addition, 
change,  or  deletion  to  the  TCMD  record  and  or  pallet  header. 


MENU 

FULL 

HHT 

LOCAL 

DATA  TRANSFERS 

DATA 

OPTIONS 

SCREENS 

SCREENS 

REPORTS 

MESSAGES 

FIELD* 

a.  1 

3 

0 

0 

6 

5-26 

*b.  0 

0 

0 

0 

0 

0 
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1.2.2  CMOS  to  MAC  HOST;  database  validation. 

a.  Transmit  to  the  MAC  HOST  detailed  data  on  all  TCNs,  TCMDs,  and 
pallets  on  hand.  Format  and  times  to  be  specified  by  HQ  MAC  at  a 
later  date. 


MENU  FULL  HHT  LOCAL  DATA  TRANSFERS  DATA 

OPTIONS  SCREENS  SCREENS  REPORTS  MESSAGES  FIELDS 
a.  1  1  00  1  <5 


1.2.3  MAC  MACA  to  CMOS;  ATCMD . 

a.  Accept  ATCMD  data  from  the  MAC  MACA. 

b.  Accept  an  ATCMD  cancellation  notice  from  MACA,  change  the  status 
of  the  ATCMD  record  to  "cancel",  and  purge  the  ATCMD  from  the  data 
base. 

c.  Delete  ATCMDs  if  cargo  is  not  received  within  30  days. 


MENU 

FULL 

HHT 

LOCAL 

DATA  TRANSFERS 

DATA 

OPTIONS 

SCREENS 

SCREENS 

REPORTS 

MESSAGES 

FIELDf 

a . 

0 

0 

0 

0 

1 

0 

b. 

0 

0 

0 

0 

1 

0 

*c . 

0 

0 

0 

0 

0 

0 

1.2.4  CMOS  to  MAC  HOST;  intermittent  reports. 

a.  Prepare  automatically  and  electronically  transmit  reports  to  the 
HOST.  Format  and  times  to  be  specified  by  HQ  MAC  at  a  later  date. 


a . 


MENU 

OPTIONS 


FULL  HHT  LOCAL  DATA  TRANSFERS  DATA 

SCREENS  SCREENS  REPORTS  MESSAGES  FIELDS 

1  0  0  1  <  5 


JL 


1.2.5  CMOS  to  MAC  MACA;  no  ATCMD  on  file. 


a .  Notify  MAC  MACA  for  each  piece  of  cargo  arriving  at  the  port  with 
no  ATCMD  on  file.  Accept  response  of  ATCMD  data  as  available. 


MENU  FULL  HHT  LOCAL  DATA  TRANSFERS  DATA 

OPTIONS  SCREENS  SCREENS  REPORTS  MESSAGES  FIELDS 
a.  1  1  00  2  <5 


1.2.6  ADAM  III  (DPS-6 )  to  CMOS;  initialization. 

a.  Transfer  ADAM  III  data  to  the  CMOS  data  base  at  implementation. 


MENU  FULL  HHT  LOCAL  DATA  TRANSFERS  DATA 

OPTIONS  SCREENS  SCREENS  REPORTS  MESSAGES  FIELDS 
a.  1  1  00  1  <5 


1.3  NAF/ALD. 

1.3.1  NAF/ALD  terminals. 

a.  Provide  CMOS  terminals  for  each  MAC  NAF  and  ALD.  These  terminals 
will  be  connected  to  the  CMOS  CPU  at  the  location.  MAC  NAFs  are 
located  at  McGuire  AFB  and  Travis  AFB.  MAC  ALDs  are  located  at 
Ramstein  AB  and  Hickam  AFB. 


MENU  FULL  HHT  LOCAL  DATA  TRANSFERS  DATA 

OPTIONS  SCREENS  SCREENS  REPORTS  MESSAGES  FIELDS 
*a .  0  0  0  0  0  0 


1.3.2  NAF/ALD  data. 

a.  Provide  the  same  read  only  capabilities  found  in  the  APCC 
function. 
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(1)  Display  current  tonnage  of  pal3fets  on-hand  and  movement 
ready  for  each  APOD  selected. 

(2)  Display  current  tonnage  of  pallets  and  loose  cargo  on-hand 
and  movement  ready  for  each  APOD  selected. 

( 3 )  Display  current  tonnage  of  unprocessed  cargo  on-hand  for 
each  APOD  selected. 

(4)  Display  cargo  on-hand  by  each  APOD  within  a  specified  area. 
These  areas  are  displayed  by  Management  Action  Indicators 
(MAI) 

descriptions . 

(5)  Provide  a  capability  to  call  up  reports  (TRAIS  like)  for 
subordinate  ports. 


MENU 

FULL 

HHT 

LOCAL 

DATA  TRANSFERS 

DATA  j 

OPTIONS 

SCREENS 

SCREENS 

REPORTS 

MESSAGES 

FIELDS  j 

a.  1 

23 

0 

0 

22 

o  ! 

.3.3  NAF/ALD  reports . 

.3.3.1  Regular  reports. 

a .  Aggregate 

port  provided 

information  into 

NAF/ALD  defined  summary 

reports .  Format  and  times 

to  be  specified  by  HQ  MAC  at  a 

later  date 

i  MENU 

FULL 

HHT 

LOCAL 

DATA  TRANSFERS 

DATA  ! 

!  OPTIONS 

SCREENS 

SCREENS 

REPORTS 

MESSAGES 

FIELDS  j 

!  a.  1 

1 

0 

0 

1 

<  5  | 

.3.3.2  Intermittent  reports. 

a .  Aggregate 

port  provided 

information  into 

NAF/ALD  defined  summary 

reports .  Format  and  times 

to  be  s 

pecified  by  HQ  MAC  at  a 

later  date 

!  MENU 

FULL 

HHT 

LOCAL 

DATA  TRANSFERS 

DATA  | 

j  OPTIONS 

SCREENS 

SCREENS 

REPORTS 

MESSAGES 

FIELDS  | 

!  a.  1 

1 

0 

0 

1 

<  5  j 

1.4  Air  Terminal  Support  Activity  (ATSA) . 

1.4.1  ATSA  terminals. 

a.  Provide  CMOS  terminals  for  each  ATSA  collocated  with  a  MAC  aerial 
port.  These  terminals  will  be  connected  to  the  CMOS  CPU  at  the 
location. 


MENU 

FULL 

HHT 

LOCAL 

DATA  TRANSFERS 

DATA  | 

OPTIONS 

SCREENS 

SCREENS 

REPORTS 

MESSAGES 

FIELDS  i 

{  *a. 

0 

0 

0 

0 

0 

o  i 

1.4.2  Cargo  visibility. 

a.  Provide  read  only  visibility  of  all  cargo  in  the  aerial  port  and 
outbound  surface  freight. 

b.  Provide  read  only  visibility  of  advanced  manifest  data  for  inbound 


air  shipments  and  advanced 
inbound  surface  shipments 

movement 

4 

data  for 

intransit  cargo 

on 

MENU 

FULL 

HHT 

LOCAL 

DATA  TRANSFERS 

DATA 

OPTIONS 

SCREENS 

SCREENS 

REPORTS 

MESSAGES 

FIELDS 

a .  1 

1 

0 

0 

0 

0 

b.  1 

3 

0 

0 

0 

0 

1.4.3  Edit  TCMD . 

a.  Review,  add,  change,  and  delete  ATCMD  prime  and  trailer  data  for 
cargo  inbound  to  the  aerial  port. 

b.  Modify  "approved"  ATCMDs  received  from  HQ  MAC  MACA  (CONUS)  or  from 
CMOS  or  DAMMS-R  (overseas). 

c.  Build  ATCMDs  for  cargo  that  arrives  at  the  port  with  no  ATCMD  on 
file  using  updates  from  MACA  or  TCMD  information  on  the  inbound 
shipping  document. 


d.  Do  not  allow  creation  of  an  ATCMD  with  a  non-significant  TAC. 

e.  Change  the  status  of  the  ATCMD  record  to  "cancel,"  and  purge  the 
ATCMD  from  the  data  base. 


MENU 

FULL 

HHT 

LOCAL 

DATA  TRANSFERS 

DATA 

OPTIONS 

SCREENS 

SCREENS 

REPORTS 

MESSAGES 

FIELDS 

a . 

1 

1 

0 

0 

0 

0 

b. 

1 

1 

0 

0 

0 

0 

c. 

1 

2 

12 

0 

0 

0 

d. 

0 

1 

0 

0 

0 

0 

e. 

1 

1 

0 

0 

0 

0 

1.4.4  Change  movement  priority /mode . 

a.  Initiate  action  to  upgrade  movement  priority  (greensheet ) , 
downgrade  movement  priority,  or  change- modes  for  cargo  on-hand. 

b.  Accept  changes  to  the  TCMD  record  from  aerial  port  personnel. 


MENU 

FULL 

HHT 

LOCAL 

DATA  TRANSFERS 

DATA 

OPTIONS 

SCREENS 

SCREENS 

REPORTS 

MESSAGES 

FIELDS 

a . 

1 

1 

0 

0 

0 

0 

*b. 

0 

0 

0 

0 

0 

0 

1.4.5  Edit  consignee  DODAAC. 

a.  Modify  the  consignee  DODAACs  associated  with  Navy  vessels. 

b.  Adjust  POD  data  for  all  TCMDS  with  the  modified  DODAAC. 

c.  Notify  air  freight  ‘to  change  the  bay  location  of  cargo  in  the 
aerial  port. 


MENU 

FULL 

HHT 

LOCAL 

DATA  TRANSFERS 

DATA 

OPTIONS 

SCREENS 

SCREENS 

REPORTS 

MESSAGES 

FIELDS 

a . 

1 

1 

0 

0 

0 

0 

b. 

I 

1 

0 

0 

0 

0 

c , 

0 

0 

0 

1 

0 

0 

1.4.6  Onward  movement  by  organic  air. 


a .  Identify  outbound  surface  cargo  and  inbound  air  cargo  for  onward 
movement  by  organic  air. 

b.  Modify  the  mode  code  and  notify  surface  freight  electronically  to 
move  the  cargo  to  a  new  bay  location  for  cargo  scheduled  to  move  by 
outbound  surface. 

c.  Modify  the  bay  location  for  cargo  scheduled  to  arrive  by  air. 


MENU 

FULL 

HHT 

LOCAL 

DATA  TRANSFERS 

DATA 

OPTIONS 

SCREENS 

SCREENS 

REPORTS 

MESSAGES 

FIELDS 

a  * 

0 

0 

0 

0 

0 

0 

t>4 

1 

1 

0 

1 

0 

0 

C  . 

1 

0 

0 

0 

0 

0 

1.4.7  Validate  ATCMD  (overseas  ATSAs ) . 

a.  Validate  ATCMD  data  received  from  shippers  (CMOS  and  DAMMS-R)  and 
immediately  transmit  this  information  to  the  aerial  port. 


MENU  FULL  HHT  LOCAL  DATA  TRANSFERS  DATA 

OPTIONS  SCREENS  SCREENS  REPORTS  MESSAGES  FIELDS 
a.  0  0  00  10 


1.5  Inbound  Surface. 

1.5.1  Truck  arrival  time. 

a.  Enter  truck  arrival  time  through  the  HHT  or  PC. 


MENU  FULL  HHT  LOCAL  DATA  TRANSFERS  DATA 

OPTIONS  SCREENS  SCREENS  REPORTS  MESSAGES  FIELDS 
a.  1  1  6  0  0  <5 


1.5.2  Verify  air  clearance. 


a .  Receive  and  store  ATCMD  data . 

b.  Verify  ATCMD  data  has  been  received  for  a  shipment.  This 
capability  will  be  available  to  both  the  PC  workstation  and  hand-held 
terminal  operators,  and  support  incheck  with  or  without  prepositioned 
data . 

c.  Require  ATCMDs  for  all  shipments  except  mail,  MAC  MICAP,  WIP,  FSS, 
and  SAAM  cargo,  armed  forces  courier  material,  and  code  J  baggage. 


MENU 

FULL 

HHT 

LOCAL 

DATA  TRANSFERS 

DATA 

OPTIONS 

SCREENS 

SCREENS 

REPORTS 

MESSAGES 

FIELDS 

a. 

0 

0 

0 

0 

1 

<  5 

b. 

1 

2 

12 

0 

0 

<  5 

*c. 

0 

0 

0 

0 

0 

0 

1.5.2. 1  No  ATCMD  on  file. 

a.  Advise  the  in-checker  automatically,  through  the  HHT  or  PC,  if  no 
ATCMD  is  on  file. 

b.  Build  a  prime  TCMD  for  the  item  with  a  non-significant  TAC. 

c.  Pass  the  data  electronically  to  the  ATSA  for  completion. 

d.  Change  the  shipment  status  to  "INC"  automatically  and  store  the 
cargo  in  the  ATSA  bay  location  until  the  TCMD  data  is  completed. 

e.  Change  the  shipment  status  to  "PRO"  automatically  when  the  ATSA 
completes  the  TCMD. 


MENU 

FULL 

HHT 

LOCAL 

DATA  TRANSFERS 

DATA 

OPTIONS 

SCREENS 

SCREENS 

REPORTS 

MESSAGES 

FIELDS 

a. 

1 

1 

6 

0 

0 

0 

b. 

1 

2 

12 

0 

0 

0 

c . 

0 

0 

0 

0 

1 

0 

*d . 

0 

0 

0 

0 

0 

0 

e . 

0 

0 

0 

0 

1 

0 

1.5. 2. 2  Notify  MACA. 


a.  Notify  the  MAC  MACA  electronically  that  no  ATCMD  data  is  on  hand. 

b.  Accept  a  response  ATCMD  from  the  MAC  MACA  if  it  is  available. 


MENU 

FULL 

HHT 

LOCAL 

DATA  TRANSFERS 

DATA 

OPTIONS 

SCREENS 

SCREENS 

REPORTS 

MESSAGES 

FIELDS 

a. 

0 

0 

0 

0 

1 

0 

b. 

0 

0 

0 

0 

1 

0 

1.5. 2. 3  Non-significant  TAC. 

a.  Pass  ATCMD  data  to  the  ATSA  for  validation  and  assignment  of  a 
proper  TAC  if  an  ATCMD  is  on  file  but  has  a  non-significant  TAC. 

b.  Change  the  cargo  status  to  "INC"  automatically  until  the  ATSA 
corrects  the  TAC. 

c.  Change  the  cargo  status  to  "PRO"  automatically  when  the  ATSA 
corrects  the  TAC. 


MENU 

FULL 

HHT 

LOCAL 

DATA  TRANSFERS 

DATA 

OPTIONS 

SCREENS 

SCREENS 

REPORTS 

MESSAGES 

FIELDS 

a  • 

0 

0 

0 

0 

0 

0 

b. 

0 

0 

0 

0 

0 

0 

c . 

0 

0 

0 

0 

0 

0 

1.5. 2. 4  Visibility  to  load  planner. 

a.  Restrict  the  load  planner's  visibility  over  cargo  in  the  "INC" 
status . 


MENU  FULL  HHT  LOCAL  DATA  TRANSFERS  DATA 

OPTIONS  SCREENS  SCREENS  REPORTS  MESSAGES  FIELDS 

*a .  0  0  0  0  0  0 


1.5.3  In-check  information. 


1.5. 3.1  Validate  shipper  authenticity. 

a.  Determine  if  the  consignee  DODAAC  for  each  arriving  shipment  is 
valid,  using  advanced  shipment  information. 

b.  Notify  the  system  manager  of  discrepancies.  The  system  manager 
will  update  the  CMOS  consignee  information. 

c.  Frustrate  shipments  (status  code  "FRE")  and  notify  the  ATSA  to 
either  modify  the  shipment  consignee  DODAAC  or  update  the  CMOS 
consignee  information  if  a  shipment  is  found  without  a  valid  consignee 


DODAAC 

during 

incheck  by 

either  a  PC 

workstation 

or  HHT. 

MENU 

FULL 

HHT 

LOCAL  DATA  TRANSFERS 

DATA 

OPTIONS 

SCREENS 

SCREENS 

REPORTS 

MESSAGES 

FIELDS 

a« 

1 

1 

6 

0 

0 

0 

b. 

1 

1 

0 

0 

1 

0 

c. 

0 

0 

0 

0 

1 

0 

1 . 5 . 3 . 2  Probable  bay  location . 

a.  Display  a  probable  bay  location  for  each  item  inchecked  during 
incheck  by  either  a  PC  workstation  of  HHT. 

b.  Maintain  a  separate  bay  location  for  general,  MICAP,  999,  personal 
baggage,  household  goods,  and  special  handling  shipments. 

c.  Permit  the  in-checker  to  accept  or  override  the  probable  bay 
location . 


1.5. 3. 3  Probable  onward  movement  mode. 


a.  Display  a  probable  onward  movement  mode  for  the  shipment  by  either 
a  PC  workstation  of  HHT. 

b.  Support  all  mode  codes  in  DOD  4500. 32R. 

c.  Accept  or  override  the  probable  mode  code. 

d.  Update  the  TCMD  information  for  the  shipment  automatically. 


MENU 

FULL 

HHT 

LOCAL 

DATA  TRANSFERS 

DATA  j 

OPTIONS 

SCREENS 

SCREENS 

REPORTS 

MESSAGES 

FIELDS  | 

a« 

0 

1 

6 

0 

0 

0 

b. 

0 

0 

0 

0 

0 

<5 

c. 

1 

1 

6 

0 

0 

0 

*d . 

0 

0 

0 

0 

0 

0 

1.3.4 

Reoriginate 

cargo « 

a.  Reoriginate  intransit 

cargo  in  the  surface  or  air  freight  termin. 

based 

on  the  onward  movement  mode  code. 

MENU 

FULL 

HHT 

LOCAL 

DATA  TRANSFERS 

DATA 

OPTIONS 

SCREENS 

SCREENS 

REPORTS 

MESSAGES 

FIELDS 

a  • 

1 

1 

0 

0 

0 

0 

1.5.4  Cargo  release  procedures. 

a.  Release  material  to  the  consignee  during  in-check  using  either  the 
HHT  or  PC  workstation. 

b.  Record  the  name  and  organization  of  the  recipient  for  each  piece 
released. 


c.  Identify  cargo  that  requires  the  signature  of  the  recipient  and 
produce  a  list  with  a  signature  block. 


d.  Update  all  cargo  records  with  the  recipient's  name  e 
organization,  and  a  note  that  a  signed  transfer  documen'  ■  >n  file. 

e.  Archive  the  released  cargo  record  after  elapsed  time  fic-..<  ^ 
specified  by  HQ  MAC. 


MENU 

FULL 

HHT 

LOCAL 

DATA  TRANSFERS 

DATA 

OPTIONS 

SCREENS 

SCREENS 

REPORTS 

MESSAGES 

FIELDS 

a 

1 

2 

12 

0 

0 

0 

b 

0 

0 

0 

0 

0 

<5 

c 

0 

0 

0 

1 

0 

<5 

d 

0 

0 

0 

0 

0 

<5 

e 

0 

0 

0 

0 

0 

<5 

i  Inbound  Air. 

;.i 

Aircraft 

arrival  time. 

* 

a . 

Enter  aircraft  arrival 

time  through  the  HHT  or  PC. 

MENU 

FULL 

HHT 

LOCAL 

DATA.  TRANSFERS 

DATA 

OPTIONS 

SCREENS 

SCREENS 

REPORTS 

MESSAGES 

FIELDS 

a 

1 

1 

6 

0 

0 

0 

1.6.2  Manifest  in-check  procedures. 

a.  Provide  the  capability  to  in-check  a  manifest  by  line  item, 
pallet,  or  by  accepting  all  loose  cargo  or  an  entire  manifest. 

b.  Frustrate  cargo  automatically  (with  status  code  "FRE")  when 
in-check  is  done  and  an  item  is  found  with  no  DODAAC/APOD  in  the 
consignee  file. 
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c.  Notify  the  system  manager  or  ATSA  that  a  record  for  the 
DODAAC / APOD  needs  to  be  established  in  the  consignee  file. 


MENU 

FULL 

HHT 

LOCAL 

DATA  TRANSFERS 

DATA 

OPTIONS 

SCREENS 

SCREENS 

REPORTS 

MESSAGES 

FIELD! 

a . 

1 

1 

0 

0 

0 

<5 

*b 

0 

0 

0 

0 

0 

0 

c« 

0 

0 

0 

1 

1 

0 

1.6.3  In-check  information . 

1.6. 3.1  alidate  shipper  authenticity . 

a.  Determine  if  the  consignee  DODAAC  for  each  arriving  shipment  is 
valid,  using  advanced  manifest  information. 

b.  Notify  the  system  manager  of  discrepancies.  The  system  manager 
will  update  the  CMOS  consignee  information. 

c.  Frustrate  shipments  (status  code  "FRE")  and  notify  the  ATSA  to 
either  modify  the  shipment  consignee  DODAAC  or  update  the  CMOS 
consignee  information  if  a  shipment  is  found  without  a  valid  consignee 
DODAAC  during  in-check  by  either  a  PC  workstation  or  HHT. 


MENU 

FULL 

HHT 

LOCAL 

DATA  TRANSFERS 

DATA 

OPTIONS 

SCREENS 

SCREENS 

REPORTS 

MESSAGES 

FIELDS 

a  ♦ 

1 

1 

6 

0 

0 

0 

b. 

0 

0 

0 

0 

0 

0 

c . 

0 

0 

0 

0 

0 

0 

1.6. 3. 2  Probable  bay  location. 

a.  Display  a  probable  bay  location  for  each  item  in-checked  by  either 
a  PC  workstation  or  HHT. 

b.  Maintain  a  separate  bay  location  for  general,  MJ.CAP,  9S9,  personal 
baggage,  household  goods,  and  special  handling  shipments. 


c.  Permit  the  in-checker  to  accept  or  override  the  probable  bay- 
location. 


MENU 

FULL 

HHT 

LOCAL 

DATA  TRANSFERS 

DATA 

OPTIONS 

SCREENS 

SCREENS 

REPORTS 

MESSAGES 

FIELDS 

a. 

0 

1 

6 

0 

0 

0 

b. 

0 

0 

0 

0 

0 

0 

c. 

1 
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1.6. 3. 3  Probable  onward  movement  mode. 

a.  Display  a  probable  onward  movement  mode  for  the  shipment  during 
in-check  by  either  a  PC  workstation  of  HHT. 

b.  Support  all  mode  codes  in  DOD  4500. 3 2R. 

c.  Accept  or  override  the  probable  mode  code. 

d.  Update  the  TCMD  information  for  the  shipment  automatically. 
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1.6. 3. 4  Reoriginate  cargo. 

a.  Reoriginate  intransit  cargo  in  the  surface  or  air  freight  terminal 
based  on  the  onward  movement  mode  code. 


MENU  FULL  HHT  LOCAL  DATA  TRANSFERS  DATA 

OPTIONS  SCREENS  SCREENS  REPORTS  MESSAGES  FIELDS 
*a .  0  0  0  0  0  0 
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1.6.4  Cargo  release  procedures . 


a.  Release  material  to  the  consignee  during  in-check  using  either  the 
HHT  or  PC  workstation. 

b.  Record  the  name  and  organization  of  the  recipient  for  each  piece 
released. 

c.  Identify  cargo  that  requires  the  signature  of  the  recipient  and 
produce  a  list  with  a  signature  block. 

d.  Update  all  cargo  records  with  the  recipient's  name  and 
organization,  and  a  note  that  a  signed  transfer  document  is  on  file. 

e.  Archive  the  released  cargo  record  after  elapsed  time  frame 
specified  by  HQ  MAC. 
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1.6.5  MAC  host  update  for  outbound  surface. 

a.  Prepare  automatically  and  transmit  electronically  a  lifted  manifest 
transaction  to  the  HQ  MAC  HOST  when  the  aerial  port  releases  the  cargo 
for  onward  surface  movement. 


MENU  FULL  HHT  LOCAL  DATA  TRANSFERS  DATA 

OPTIONS  SCREENS  SCREENS  REPORTS  MESSAGES  FIELDS 

a.  0  0  00  10 


1.6.6  Over/ short  shipments . 


a.  Manage  over/short  shipments  for  MILSTAMP  mode  code  "F"  cargo. 


MENU  FULL  HHT  LOCAL  DATA  TRANSFERS  DATA 

OPTIONS  SCREENS  SCREENS  REPORTS  MESSAGES  FIELDS 
a.  0  0  0  0  0  5-26 


1 . 6 . 6 . 1  Over  shipments  received  at  intended  destination . 

1 . 6 . 6 . 1 . 1  Over  shipment  on-hand . 

a.  Check  an  over  shipment  against  the  over/short  register  at  the 
receiving  station  to  see  if  the  shipment  was  identified  earlier  as  a 
short  shipment. 

b.  Add  the  shipment  to  the  over  shipment  register  if  not  previously 
identified. 

c.  Notify  the  system  manager  of  the  over  shipment,  the  identity  of  the 
origin  station,  and  the  identities  of  enroute  stations. 

d.  Provide  the  system  manager  with  the  capability  to  select  stations  that 
could  have  been  responsible  for  the  overage. 

e.  Generate  an  over  shipment  message  to  each  of  these  stations. 
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1 . 6 . 6 . 1 . 2  Over  shipment  message  response . 


a.  Accept  notification  of  an  over  shipment  and  automatically  determine 
if  the  shipment  was  handled. 


MENU  FULL  HHT  LOCAL  DATA  TRANSFERS  DATA 

OPTIONS  SCREENS  SCREENS  REPORTS  MESSAGES  FIELDS 
a.  0  0  0  0  1  5-26 


1 . 6 . 6 . 1 . 2 . 1  Over  shipment  not  handled . 

a.  Advise  electronically  the  requesting  CMOS  that  the  shipment  was  not 
handled  if  no  record  exists. 


MENU  FULL  HHT  LOCAL  DATA  TRANSFERS  DATA 

OPTIONS  SCREENS  SCREENS  REPORTS  MESSAGES  FIELDS 
a.  0  0  0  0  1  5-26 


1 . 6 . 6 . 1 . 2 . 2  Over  shipment  handled ;  onward  movement  unrecorded . 

a.  Generate  automatically  a  "dummy"  manifest  using  the  manifest  number 
from  the  over  shipment  message  and  the  next  available  manifest  number, 
if  a  record  exists  with  no  outbound  mission  data. 

b.  Send  the  "dummy"  manifest  to  the  MAC  HOST  and  the  destination 
station  automatically  by  electronic  means. 

c.  Clear  the  item  from  the  over/short  shipment  register  at  the 
destination . 
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1.6. 6. 1.2. 3  Over  shipment  handled;  onward  movement  recorded. 


* 


a.  Send  automatically  a  message  containing  outbound  mission 
information  to  the  CMOS  generating  the  over  shipment  message  if  a 
record  exists  with  outbound  mission  data. 

b.  Flag  the  over  shipment  pending  arrival  of  the  mission  at  the  CMOS 
generating  the  over  shipment  message. 
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1.6. 6. 2  Over  shipments  received  at  other  than  the  intended  destination. 

1 . 6 . 6 . 2 . 1  Over  shipment  on-hand . 

a.  Check  an  over  shipment  against  the  over/short  register  to  see  if 
the  shipment  was  identified  earlier  as  a  short  shipment. 

b.  Add  the  shipment  to  the  over  shipment  register  if  previously 
identified  as  a  short  shipment. 

c.  Notify  the  system  manager  of  the  over  shipment/  the  identity  of  the 
origin  station,  and  the  identities  of  enroute  stations. 

d.  Provide  the  system  manager  with  the  capability  to  select  stations 
that  could  have  been  responsible  for  the  overage. 

e.  Generate  an  over  shipment  message  to  each  of  these  stations. 
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1 . 6 . 6 . 2 . 2  Over  shipment  message  response . 


a.  Accept  notification  of  an  over  shipment  and  automatically  determine 
if  the  shipment  was  handled. 
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1.6. 6. 2. 2. 2  Over  shipment  handled;  onward  movement  unrecorded. 

a.  Generate  automatically  a  "dummy"  manifest  using  the  manifest  number 
from  the  over  shipment  message  and  the  next  available  manifest  number, 
if  a  record  exists  with  no  outbound  mission  data. 

b.  Send  the  "dummy"  manifest  to  the  MAC  HOST  and  the  destination 
station  automatically  by  electronic  means. 

c.  Clear  the  item  from  the  over/short  shipment  register  at  the 
destination. 


d.  Reoriginate  the  shipment  for  onward  movement. 
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1 . 6 . 6 . 2 . 2 . 3  Over  shipment  handled ;  onward  movement  recorded . 

a.  Send  automatically  a  message  containing  outbound  mission 
information  to  the  CMOS  generating  the  over  shipment  message  if  a 
record  exists  with  outbound  mission  data. 

b.  Modify  the  TAC  for  the  over  shipped  item  ("S"  in  the  second 
position)  and  reoriginate  the  shipment  to  its  intended  destination. 

c.  Return  the  TAC  to  its  original  composition  upon  arrival  at  the 
intended  destination. 
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1 . 6 . 6 . 3  Short  shipments . 

1.6. 6. 3.1.  Short  shipment  record  on-hand  without  cargo. 

a.  Check  a  short  shipment  against  the  over/short  register  at  the 
intended  destination  to  see  if  the  shipment  was  identified  earlier  as 
an  over  shipment. 

b.  Add  the  shipment  to  the  short  shipment  register  if  not  previously 
identified . 


c.  Notify  the  system  manager  of  the  short  shipment,  the  identity  of 
the  origin  station,  and  identities  of  enroute  stations. 

d.  Provide  the  system  manager  with  the  capability  to  select  stations 
that  could  have  been  responsible  for  the  shortage. 

e.  Generate  a  short  shipment  message  to  each  of  these  stations. 
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1.6. 6. 3. 2  Short  shipment  message  response. 

a.  Accept  notification  of  a  short  shipment  and  automatically  determine 
if  the  shipment  was  handled. 


MENU  FULL  HHT  LOCAL  DATA  TRANSFERS  DATA 

OPTIONS  SCREENS  SCREENS  REPORTS  MESSAGES  FIELDS 
a.  0  0  0  0  1  5-26 


1.6. 6. 3. 2.1  Short  shipment  not  handled. 

a.  Advise  electronically  the  requesting  CMOS  that  the  shipment  was  not 
handled  if  no  record  exists . 


MENU  FULL  HHT  LOCAL  DATA  TRANSFERS  DATA 

OPTIONS  SCREENS  SCREENS  REPORTS  MESSAGES  FIELDS 
a.  0  0  0  0  1  5-26 


1 . 6 . 6 . 3 . 2 . 2  Short  shipment  located ;  on-hand . 

a.  Reoriginate  the  shipment  and  modify  the  TAC  ("S"  in  the  second 
position)  for  the  item. 

b.  Notify  electronically  the  CMOS  generating  the  short  shipment 
message  that  the  cargo  is  on-hand. 

c.  Flag  the  short  shipment  record  pending  receipt  of  the  cargo  at  the 
CMOS  generating  the  short  shipment  message. 

d.  Return  the  TAC  to  its  original  composition  upon  arrival  of  the 
cargo  at  the  intended  destination. 

e.  Transmit  automatically  a  follow-up  message  to  the  station  that 
reported  the  cargo  on-hand  for  shipments  not  received  within  72  hours 
of  being  flagged. 
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1 . 6 . 6 . 3 . 2 . 3  Short  shipment  handled ;  onward  movement  recorded . 

a.  Send  a  message  with  mission  information  to  the  CMOS  generating  the 
short  shipment  message  if  the  cargo  has  been  shipped. 

b.  Flag  the  short  shipment  record  pending  arrival  of  the  mission. 

c.  Transmit  automatically  a  follow-up  message  to  the  station  that 
reported  the  cargo  on-hand  if  the  cargo  is  not  received  within 
manifest  ETA  plus  24  hours. 

d.  Retransmit  a  short  shipment  message  to  the  station  which  reported 
the  mission  information  if  an  abort  manifest  transaction  is  received 


for  the  mission  on  which  the  previously  shorted  piece  was  scheduled  to 
arrive . 
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1 . 6 . 6 . 3 . 3  Unresolved  short  shipments . 

a.  Notify  the  system  manager  to  manually  prepare  an  SF361  if  the  short 
shipment  is  not  resolved  in  21  days. 

b.  Provide  a  history  of  system  messages  (outbound  and  inbound) 
associated  with  locating  the  short  shipment. 

c.  Do  not  remove  items  from  the  short  shipment  register  unless  the 
short  shipment  has  been  resolved  or  SF361  data  is  entered. 
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1 . 6 . 6 . 4  System  manager  review . 

a.  Display  the  over/short  shipment  register,  the  status  of  items  in 
the  register,  and  the  inbound  over /short  messages  received  with 
associated  responses  for  system  manager  review. 


MENU  FULL  HHT  LOCAL  DATA  TRANSFERS  DATA 

OPTIONS  SCREENS  SCREENS  REPORTS  MESSAGES  FIELDS 

a.  1  2  00  00 


1.7  Special  Handling. 


a.  Segregate  the  processing  of  cargo  having  selected  air  commodity, 
special  handling  codes,  and  MAC  MICAP. 

b.  Perform  all  the  functions  of  inbound  air  and  surface  freight;  and 
the  in-check,  palletization/containerization,  inventory,  and  TCMD 
modification  capabilities  of  outbound  air  and  surface  freight. 
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1.8  Outbound  Air. 

1.8.1  Probable  onward  movement  mode . 

a.  Display  the  probable  onward  movement  mode  on  the  shipment  planning 
input  screen  for  mode  selection  during  cargo  origination. 


MENU  FULL  HHT  LOCAL  DATA  TRANSFERS  DATA 

OPTIONS  SCREENS  SCREENS  REPORTS  MESSAGES  FIELDS 
a.  0  1  00  00 


1.8.2  Identify  palletization  requirements. 

a.  Identify  cargo  requiring  palletization  by  air  freight  to  the  load 
planner. 


MENU  FULL  HHT  LOC/iL  DATA  TRANSFERS  DATA 

OPTIONS  SCREENS  SCREENS  REPORTS  MESSAGES  FIELDS 
a.  1  1  0  0  0  <5 


1.8.3  Pallet  buildup. 

a.  Create  a  pallet  header  shell. 

b.  Add  items  to  the  pallet. 

c.  Cap  the  pallet. 

d.  Sum  the  weights  of  the  items  on  the  pallet  plus  the  standard  pallet 
and  strap  weights;  enter  this  sum  as  the  pallet  weight  on  the  movement 
document . 

e.  Prevent  record  changes  to  capped  pallets. 

f.  Accept  grid  location  for  the  capped  pallet  from  the  operator. 

g.  Display  a  warning  when  incompatible  hazardous  cargo  either 
palletized  or  loose,  is  being  load  planned. 


MENU 

FULL 

HHT 

LOCAL 

DATA  TRANSFERS 

DATA 

OPTIONS 

SCREENS 

SCREENS 

REPORTS 

MESSAGES 

FIELDJ 

a. 

1 

1 

0 

0 

0 

0 

b. 

0 

1 

0 

0 

0 

0 

*c  • 

0 

0 

0 

0 

0 

0 

d. 

0 

0 

0 

0 

0 

<5 

e. 

0 

1 

0 

0 

0 

0 

f . 

1 

1 

0 

0 

0 

0 

g* 

0 

1 

0 

0 

0 

<5 

1.8.3  Pallet  weight  verification. 

a.  Accept  the  actual  weight  of  a  capped  pallet  from  the  operator  and 
compare  it  to  the  pallet  weight  on  the  movement  document. 

b.  Test  the  difference  against  the  ranges  found  in  MACR  76-1. 

c.  Change  pallet  status  automatically  to  "INC"  (not  movement  ready), 
if  the  maximum  allowable  difference  is  exceeded. 


d.  Notify  the  PC  operator,  and  display  pallet  contents  for  review 
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1.8.4  Load  planning  schematic. 

a.  Produce  a  Load  Pull  Sheet  and  Load/Sequence  Breakdown  Worksheet  or 
load  planning  schematic. 

b.  Pass  the  schematic  to  air  freight  personnel. 
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.5  Management  Action  Indicator  (MAI) 

a.  Establish  and  maintain 

MAIs. 

b.  Display  cargo  backlogs 

and  load  planning 

lists  using  MAIs 

i  . 
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1.8.6  Multiple  manifests. 


a.  Allow  preparation  of  multiple  air  manifests  for  the  same  mission. 


MENU  FULL  HHT  LOCAL  DATA  TRANSFERS  DATA 

OPTIONS  SCREENS  SCREENS  REPORTS  MESSAGES  FIELDS 
a.  1  1  00  00 


1.9  Outbound  Surface. 

1.9.1  Probable  onward  movement  mode . 

a.  Display  the  probable  onward  movement  mode  on  the  shipment  planning 
input  screen  fcr  mode  selection  during  cargo  origination. 


MENU  FULL  HHT  LOCAL  DATA  TRANSFERS  DATA 

OPTIONS  SCREENS  SCREENS  REPORTS  MESSAGES  FIELDS 
a.  0  1  00  00 


1.9.2  Bay  location  changes  for  onward  movement  by  organic  military  air. 

a.  Allow  the  ATSA  to  change  the  onward  movement  mode  from  surface  to 
organic  military  air. 

b.  Notify  the  outbound  surface  freight  operator  electronically  to  move 
the  cargo  to  a  new  bay  location. 
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1.9.3  Multiple  military  truck  destinations. 

a.  Manifest  trucks  to  multiple  destinations;  assign  a  manifest 
reference  number  for  each  destination. 


MENU  FULL  HHT  LOCAL  DATA  TRANSFERS  DATA 

OPTIONS  SCREENS  SCREENS  REPORTS  MESSAGES  FIELDS 
a.  1  1  0  0  0  <5 


1.10  Miscellaneous  Reports.  HQ  MAC  will  identify  preformatted  reports 
and  standard  queries  that  shall  be  required.  At  a  minimum,  the  reports 
listed  below  are  expected  to  be  required. 

a.  Produce  the  reports  and  queries  described  in  the  ADAM  III  Port 
Management  Function.  This  function  is  divided  into  three  categories: 
TRAIS  reports,  local  reports  (on-demand  and  time-generated),  and  data 
base  queries.  TRAIS  reports  represent  a  daily  snapshot  of  the  HQ  MAC 
data  base,  and  they  can  be  requested  by  the  ports. 

(1)  Local  reports.  There  are  17  local  management  reports 
available  and  7  of  these  will  be  approximated  in  CMOS. 

(a)  Local  report  4  -  Pallet  Grid  Inventory  Report 

(d)  Local  report  9  -  Cargo  by  Commodity/Special 
Handling  Code 

(e)  Local  report  10  -  Oversized/Outsized  Cargo  List 

(f)  Local  report  11  -  Excessive  PHT  and/or  SET 

(g)  Local  report  12  -  On-hand  Data  by  Project  Code  or 
TAC 

(h)  Local  report  13  -  Summary  Data  by  Project  Code  or 
TAC 

(i)  Local  report  14  -  Unchanged  Cargo  Status 

(k)  Local  report  16  -  Surface  Cargo  in  Loose  Locations 

in  Consignee  Sequence 

(l)  Local  report  17  -  ACA  Report 

(m)  Local  report  18  -  Pallet  Listing  Report 

(2).  Database  queries.  There  are  10  query  reports 
available  and  four  will  be  approximated  in  CMOS. 

(a)  Query  request  2  -  Cargo  by  APOD  and  status 

(b)  Query  request  3  -  Cargo  by  APOD  and  priority 


(c)  Query  request  4  -  Cargo  by  APOD,  status,  and 
priority 

(d)  Query  request  5  -  Cargo  by  status  and  priority 

(e)  Query  request  6  -  Cargo  by  status  and  onward  mode 

(f)  Query  request  9  -  Cargo  by  pallet  contents 

in  the  port 

(3)  TRAIS  Reports.  There  are  18  TRAIS  reports  and  none  are 
available  in  CMOS. 

(a)  Unprocessed  port  profile  on-hand 

(b)  Processing  port  profile  on-hand 

(c)  Movement  ready  pallets  on-hand 

(d)  Manifest  header  summary 

(e)  Daily  workload 

(f)  Cumulative  port  hold/processing  times 

(g)  24  hour/cumulative  movement  for  pallets 

(h)  Air  outbound  movement  report 

(i)  On-hand  cargo  report 

(j)  Inventory  of  999  old  age  cargo 

(k)  Mission  recap 

(l)  Super  priority  cargo/mail  port  total 

(m)  Deleted  records 

(n)  Detail  movement  report 

(o)  TP4  on-hand  by  channel 

(p)  TP4  movement  by  channel 

(q)  TP4  on-hand  by  category 

(r)  TP4  movement  by  category 
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Appendix  A 

Draft  Functional  Requirements  Document 


1.0  REQUIREMENTS:  The  capabilities  described  below  shall  be 
added  to  the  CMOS  software  developed  for  Increments  I  and  II. 
Unless  specifically  identified  as  applying  only  at  an  aerial 
port,  the  capabilities  shall  be  available  to  all  CMOS  users. 

1 . 1  System  Functions . 

1.1.1  Port  hold  time.  At  aerial  port  locations,  CMOS  shall 
track  and  color  code  (red/yellow/green)  air  freight  cargo 
status  based  on  port  hold  time.  Port  hold  time  begins  with 
the  actual  arrival  time  for  the  aircraft  or  truck  and  ends 
with  actual  time  of  aircraft  departure  or  when  inbound  cargo 
is  inchecked  and  identified  for  outbound  surface  movement. 
Port  hold  time  is  not  accrued  for  cargo  while  it  is 
frustrated. 

1.1.2  Cargo  tracking.  CMOS  shall  track  the  status  of  loose 
cargo  and  containers  (pallets,  MILVANS..  other  containerized 
shipments)  for  all  airlift  cargo  using  the  status  codes 
contained  in  attachment  1. 

1.1.3  Frustrated  cargo  tracking.  CMOS  shall  track  the 
status  of  loose  cargo  and  containers  using  the  codes  in 
attachment  2 . 

1.1.4  Edit  bay  location  and  mode  code .  CMOS  shall  provide 
the  capability  to  change  cargo  bay  locations  and  MILSTAMP 
mode  codes  for  cargo  and  containers  in  the  backlog  using  a  PC 
workstation  or  hand-held  terminal. 

1.1.5  TCN  edit  check.  During  incheck  or  inventory,  CMOS 
shall  conduct  edit  checks  for  TCNs  keyed  into  the  PC 
workstation  or  hand-held  terminal.  The  edit  checks  shall 
provide  information  that  will  enable  the  operator  to  isolate 
three  possible  causes  for  any  discrepancies. 

1.1. 5.1  Entry  Error.  ’*  CMOS  shall  advise  if  there  are  no 
matching  TCNs  on-hand  but  all  the  characters  are  identical  to 
another  TCN(s)  except  two.  CMOS  shall  require  the  operator 
to  verify  the  TCN.  (common  entry  errors  are  0  for  0,  L  for 
If  S  for  5,  and  D  for  0). 

1. 1.5.2  Add  TCN.  CMOS  shall  advise  if  there  are  no  matching 
TCNs  on-hand  and  more  than  2  characters  are  different.  CMOS 
shall  require  the  operator  to  enter  the  TCN. 


* 


1.1. 5. 3  Edit  TCN.  If  the  operator  determines  that  the  TCN 
was  entered  in  error  at  the  originator  station ,  the  operator 
will  be  able  to  correct  the  TCN. 

1.1.6  Inventory.  CMOS  shall  provide  the  capability  to 
inventory  cargo  using  two  methods .  For  both  methods ,  cargo 
shall  be  sorted  and  inventory  accomplished  by  bay  location. 

1.1. 6.1  Manual  inventory.  In  the  first  method,  CMOS  shall 
produce  a  hard  copy  list  of  on-hand  cargo  sorted  by  bay 
location.  This  list  will  be  compared  with  actual  cargo  in 
the  terminal  and  discrepancies  will  be  keyed  into  the  PC 
workstation. 

1.1. 6. 2  Hand-held  terminal  inventory.  In  the  second  method, 
hand-held  terminals  shall  record  actual  cargo  in  the  terminal 
by  bay  location,  compare  it  with  cargo  on-hand,  and  identify 
the  discrepancies.  If  cargo  is  found  in  the  wrong  bay 
location,  CMOS  shall  notify  the  appropriate  work  center  to 
move  the  cargo. 

1 . 1 . 6 . 3  Inventory  over/ short  procedures .  Overages 
identified  during  inventory  shall  be  checked  against  the 
short  shipment  register  and,  if  found,  shall  clear  that  entry 
from  the  register.  If  not  found,  the  ATSA  at  aerial  ports  or 
the  work  center  conducting  the  inventory  at  non-aerial  ports 
shall  be  notified  and  provided  the  capability  to  create  TCMD 
data  for  the  shipment.  Shortages  shall  be  identified  to  the 
system  manager  for  resolution. 

1 . 1 . 6 . 4  Inventory  timing  and  documentation .  The  system 
shall  prompt  the  operator  to  perform  the  inventory  based  on  a 
user  defined  time  criteria.  CMOS  shall  document  the  date, 
time,  and  results  for  each  inventory  performed. 

1.1.7  Forms  production.  CMOS  shall  provide  the  capability 
to  produce  bar-coded  Military  Shipping  Labels  and  Pallet 
Placards,  and  Special  Handling  Data/Certification. 

1.1.8  Consignee  information.  CMOS  shall  provide  the 
capability  to  support  .validation  of  shipper  authenticity, 
determination  of  probable  bay  location  and  mode  for  onward 
movement,  and  reorigination  of  intransit  cargo.  This 
capability  shall  be  maintained  and  updated  by  the  system 
manager  and,  in  special  cases,  updated  by  the  Air  Terminal 
Support  Activity  (ATSA) . 


1.1.9  Workload  reporting.  At  aerial  port  locations,  CMOS 
shall  not  report  T -WRAPS  workload  data  for  inbound/outbound 
air  freight.  Instead,  CMOS  shall  capture  and  report  aerial 


port  workload  data  necessary  to  complete  blocks  II,  III 
B,C,D,E,  IV,  and  V  of  the  RCS:MAC-TRX(M&Q) 7107  report.  The 
aerial  port  workload  data  shall  be  provided  in  monthly  and/or 
quarterly  reports.  It  shall  be  generated  automatically  at 
user  defined  intervals  or  as  an  option  of  the  Reports 
Processing  Menu. 


1.2  External  Interfaces. 

1.2.1  CMOS  to  MAC  Host;  cargo  status  update.  As  airlift 
cargo  is  received  and  processed,  CMOS  shall  electronically 
transmit  all  the  400  series  transactions  required  to  update 
the  status  of  TCMDs  and/or  pallets  to  the  HQ  MAC  Host.  The 
400  series  transactions  are  defined  in  attachment  3. 

1.2.2  CMOS  to  MAC  Host;  database  validation.  At  times 
specified  by  HQ  MAC,  CMOS  shall  electronically  transmit 
detailed  data  on  all  TCNs,  TCMDs,  and  pallets  in  the  port  to 
the  HQ  MAC  Host.  This  data  will  be  used  to  validate/update 
the  HQ  MAC  Host. 

1.2.3  MAC  MACA  to  CMOS;  ATCMD .  At  CONUS  aerial  ports,  CMOS 
shall  accept  ATCMD  data  from  the  HQ  MAC  MACA.  These  records 
shall  be  maintained  for  30  days.  If  the  cargo  has  not  been 
received  by  that  time,  they  shall  be  deleted. 

1.2.4  CMOS  to  MAC  Host;  intermittent  reports.  Upon  request 
from  HQ  MAC  Host,  the  aerial  port  CMOS  shall  automatically 
prepare  and  electronically  transmit  reports  to  the  Host. 

1.2.5  CMOS  to  MAC  MACA;  no  ATCMD  on  file.  At  CONUS  aerial 
ports,  CMOS  shall  electronically  notify  MAC  MACA  for  each 
piece  of  cargo  arriving  at  the  port  with  no  ATCMD  data  on 
file.  MAC  MACA  will  respond  back  to  the  reporting  CMOS  if 
ATCMD  data  is  available. 

1.2.6  MAC  Host  to  CMOS;  initialization. 

1.3  NAF/ALD.  The  capabilities  described  in  this  section 
shall  be  added  to  the,  LRC  capability  described  in  CMOS 
Increment  II  specification. 

1.3.1  NAF/ALD  terminals.  CMOS  terminals  will  be  provided 
for  each  MAC  NAF  and  ALD.  These  terminals  will  be  connected 
to  the  CMOS  CPU  at  the  location .  MAC  NAFs  are  located  at 
McGuire  AFB  and  Travis  AFB.  MAC  ALDs  are  located  at  Ramstein 
AB,  GE,  and  Hickam  AFB. 

1.3.2  NAF/ALD  data.  The  NAF/ALD  shall  receive  data  from 
their  subordinate  aerial  ports.  It  shall  be  able  to  display 
and  print  the  data  using  system  and  user  defined  parameters. 


1.3.3  NAF/ALD  reports.  The  NAF/ALD  shall  have  the 
capability  to  electronically  request  reports  (to  be  defined 
by  HQ  MAC)  from  subordinate  aerial  ports. 

1.3.3. 1  Regular  reports.  At  times  specified  by  HQ  MAC,  the 
aerial  port  shall  automatically  produce  and  electronically 
transmit  reports  to  designated  Numbered  Air  Force  (NAF)/Air 
Lift  Division  (ALD) . 

1.3.3. 2  Intermittent  reports.  Upon  requests  from  CMOS  NAF  or 
ALD  PC  workstations,  the  aerial  port  CMOS  shall  automatically 
prepare  and  electronically  transmit  reports  to  the  requestor. 


1.4  Air  Terminal  Support  Activity  (ATSA) .  The  term  ATSA  is 
being  used  to  describe  CMOS  functional  support  requirements 
for  the  activities  of  the  overseas  Airlift  Clearance 
Authorities  (ACA)  and  the  CONUS  Military  Air  Traffic 
Coordinating  Unit  (MATCU) .  The  capabilities  described  in 
this  section  shall  be  added  to  the  Overseas  ACA  function 
described  in  the  CMOS  Increment  I  specification. 

1.4.1  ATSA  terminals.  CMOS  terminals  will  be  provided  for 
each  ATSA  collocated  with  a  MAC  aerial  port.  These  terminals 
will  be  connected  to  the  CMOS  CPU  at  the  location. 

1.4.2  Cargo  visibility.  The  ATSA  shall  have  read  only 
visibility  of  all  cargo  in  the  aerial  port  and  outbound 
surface  freight.  In  addition,  it  shall  have  read  only 
visibility  of  advanced  manifest  data  for  inbound  air 
shipments  and  advanced  movement  data  for  intransit  cargo  on 
inbound  surface  shipments. 

1.4.3  Edit  TCMD.  The  ATSA  shall  have  the  capability  to 
review,  add,  change,  and  delete  ATCMD  prime  and  trailer  data 
for  cargo  inbound  to  the  aerial  port.  This  shall  include  the 
capability  to  modify  "approved"  ATCMDs  received  from  HQ  MAC 
MACA  (CONUS)  or  from  CMOS  and  DAMMS-R  (overseas),  or  to  build 
ATCMDs  for  cargo  that  arrives  at  the  port  with  no  ATCMD  on 
file.  The  capability,  to  build  ATCMDs  shall  allow  the  ATSA  to 
receive  updates  from  HQ  MAC  MACA  or  use  TCMD  information  that 
was  on  the  inbound  shipping  document.  The  ATSA  shall  not  be 
able  to  create  an  ATCMD  with  a  non-significant  TAC  code. 

1.4.4  Change  movement  priority /mode.  The  ATSA  shall  have 
the  capability  to  initiate  action  to  upgrade  movement 
priority  (greensheet ) ,  downgrade  movement  priority,  or  change 
modes  for  cargo  in  the  aerial  port.  C!  OS  shall  create  an 
audit  trail  for  each  of  these  actions,  capturing  the 


reason/initiator  of  the  action.  For  upgrade  action,  a  T _9 
trailer  TCMD  shall  be  generated  and  appended  to  the  prime 
TCMD  for  the  item  being  upgraded. 

1.4.5  Edit  consignee  DODAAC.  The  ATSA  shall  have  the 
capability  to  modify  the  consignee  DODAACs  associated  with 
Navy  vessels.  Modification  of  the  APOD  associated  with  the 
DODAAC  shall  automatically  adjust  the  POD  data  for  all  TCMDs 
with  that  DODAAC.  It  shall  also  notify  air  freight  to  change 
the  bay  location  of  cargo  in  the  aerial  port. 

1.4.6  Onward  movement  by  organic  air.  The  overseas  ATSAs 
shall  have  the  capability  to  identify  outbound  surface  cargo 
or  inbound  air  cargo  for  onward  movement  by  organic  air.  For 
cargo  scheduled  to  move  by  outbound  surface,  the  ATSA  action 
shall  modify  the  mode  code  and  send  a  notice  to  surface 
freight  directing  the  cargo  be  moved  to  a  new  bay  location. 
For  cargo  scheduled  to  arrive  by  air,  the  ATSA  action  shall 
modify  the  probable  mode  code  and  bay  location  for  that 
individual  item. 

1.4.7  Validate  ATCMD.  The  overseas  ATSAs  shall  validate 
ATCMD  data  received  from  shippers  (CMOS  and  DAMMS-R)  and 
immediately  make  this  information  available  to  the  aerial 
port.  This  shall  eliminate  the  CMOS  to  ADAM  III  interface 
developed  in  CMOS  Increment  I  to  pass  this  data. 

1.5  Inbound  Surface.  The  capabilities  described  in  this 
section  shall  be  added  to  the  Surface  Freight  capability 
defined  in  the  Specifications  for  CMOS  Increments  I  and  II. 

1.5.1  Truck  receipt  time.  CMOS  shall  provide  the  capability 
to  enter  the  truck  arrival  time  for  surface  shipments .  This 
shall  establish  receipt  time. 

1.5.2  Verify  air  clearance.  At  aerial  ports,  CMOS  incheck 
procedures  shall  include  the  capability  to  verify  that  ATCMD 
data  has  been  received  for  a  shipment.  This  capability  shall 
be  available  to  both  the  PC  workstation  and  hand-held 
terminal  operator,  and  support  incheck  whether  or  not 
prepositioned  shipment  data  is  available.  ATCMDs  are 
required  for  all  shipments  except  mail,  S99,  MAC  MICAP 
(Project  code  196  and  480),  and  Code  J  baggage. 

1.5. 2.1  No  ATCMD  on  file.  If  no  ATCMD  is  on  file,  the 
inchecker  shall  be  capable  of  building  a  prime  TCMD  for  the 
item  with  a  nonsignificant  TAC.  This  data  shall  be  passed  to 
the  ATSA  for  further  completion.  Until  the  TCMD  data  is 
complete,  the  cargo  will  be  stored  in  the  ATSA  bay  location 
and  the  status  shall  be  "INC."  After  the  ATSA  has  completed 
the  TCMD  information,  the  cargo  status  shall  be  changed  to 
"PRO." 


1.5. 2. 2  Notify  MACA.  At  CONUS  locations,  CMOS  shall 
electronically  notify  the  MAC  MACA  that  no  ATCMD  data  is  on 
hand.  If  an  ATCMD  is  available  at  the  MAC  MACA,  it  will 
forward  the  ATCMD  to  the  notifying  CMOS. 

1.5. 2. 3  Nonsignificant  TAC.  If  an  ATCMD  is  on  file  but  has 
a  nonsignificant  TAC,  the  TCMD  data  shall  be  passed  to  the 
ATSA  for  validation  and  assignment  of  a  proper  TAC.  Until 
the  TCMD  data  is  corrected,  the  cargo  status  shall  be  "INC." 
After  the  ATSA  has  corrected  the  TCMD  information,  the  cargo 
status  shall  be  changed  to  "PRO." 

1.5. 2. 4  Visibility  to  load  planner.  Cargo  in  the  "INC" 
status  shall  not  be  visible  to  the  load  planner. 

1.5.3  Incheck  information.  CMOS  shall  provide  the 
capability  to  validate  shipper  authenticity,  determine 
probable  bay  location  and  mode  for  onward  movement,  and 
reoriginate  intransit  cargo. 

1.5.3. 1  Validate  shipper  authenticity.  For  advanced 
shipment  information,  CMOS  shall  determine  if  the  consignee 
DODAAC  for  each  arriving  shipment  is  valid.  If  not,  CMOS 
shall  notify  the  system  manager  of  the  discrepancy  and 
provide  the  capability  to  update  the  CMOS  consignee 
information.  If  a  shipment  is  found  without  a  valid 
consignee  DODAAC  during  incheck  by  either  a  PC  workstation  or 
hand-held  terminal,  CMOS  shall  frustrate  the  shipment  (status 
code  "FRE")  and  notify  the  ATSA  to  either  modify  the  shipment 
consignee  DODAAC  or  update  the  CMOS  consignee  information. 

1 . 5 . 3 . 2  Probable  bay  location .  During  incheck  by  either  a 
PC  workstation  or  hand-held  terminal,  CMOS  shall  display  a 
probable  bay  location  for  each  item  inchecked.  A  separate 
bay  location  shall  be  maintained  for  general,  MICAP,  999, 
personal  baggage,  household  goods,  and  special  handling 
shipments.  The  inchecker  shall  be  able  to  accept  or  override 
the  probable  bay  location. 

1 . 5 . 3 . 3  Probable  onward  movement  mode .  During  incheck  by 
either  a  PC  workstation  or  hand-held  terminal,  CMOS  shall 
display  the  probable  onward  movement  mode  for  the  shipment. 
This  capability  shall  support  all  mode  codes  in  DOD 

4500. 32-R.  The  inchecker  shall  be  able  to  accept  or  override 
the  probable  mode  code.  Either  of  these  actions  shall  update 
the  TCMD  information  for  the  shipment.  For  originating 
cargo,  the  probable  onward  movement  mode  shall  appear  on  the 
input  screen  for  mode  selection  in  Shipment  Planning. 


1.5. 3. 4  Reoriginate  cargo.  Based  on  the  onward  movement 
mode  code,  CMOS  shall  reoriginate  intransit  cargo  in  the 
surface  or  air  freight  terminal,  as  appropriate. 

1.5.4  Cargo  release  procedures.  CMOS  shall  provide  the 
capability  to  release  material  to  the  consignee  during  the 
incheck  procedure  using  either  the  PC  workstation  or 
hand-held  terminal.  The  name  and  organization  of  the 
recipient  shall  be  recorded  for  each  piece  released.  If  a 
signature  is  required,  CMOS  shall  provide  the  capability  to 
identify  all  or  selected  items  on  a  manifest,  and  produce  a 
listing  for  the  cargo  recipient  to  sign.  Upon  entry  into 
CMOS  of  the  recipient's  name  and  organization,  all  records  on 
this  list  shall  be  updated  and  annotated  that  a  signed 
transfer  document  is  on  file. 

1.6  Inbound  Air.  The  capabilities  described  in  this  section 
shall  be  added  to  the  Air  Freight  capability  defined  in  the 
Specifications  for  CMOS  Increments  I  and  II. 

1.6.1  Aircraft  receipt  time.  CMOS  shall  provide  the 
capability  to  enter  the  mission  arrival  time  for  airlift 
missions.  This  shall  establish  the  receipt  time. 

1.6.2  Manifest  incheck  procedures.  CMOS  shall  provide  the 
capability  to  incheck  a  manifest  by  line  item,  pallet,  or  by 
accepting  all  loose  cargo  or  an  entire  manifest.  The  cargo 
shall  automatically  be  frustrated  (status  code  "FRE")  when 
incheck  is  done  and  an  item  is  found  with  no  DODAAC/APOD  in 
the  consignee  file.  The  system  manager  or  ATSA  shall  be 
notified  to  establish  a  record  for  the  DODAAC/APOD  in  the 
consignee  file. 

1.6.3  Incheck  information.  CMOS  shall  provide  the 
capability  to  validate  shipper  authenticity,  determine 
probable  bay  location  and  mode  for  onward  movement,  and 
reoriginate  intransit  cargo. 

1.6. 3.1  Validate  shipper  authenticity.  For  advanced 
manifest  information,  CMOS  shall  determine  if  the  consignee 
DODAAC  for  each  arriving  shipment  is  valid.  If  not,  CMOS 
shall  notify  the  system  manager  of  the  discrepancy  and 
provide  the  capability  to  update  the  CMOS  consignee 
information.  If  a  shipment  is  found  without  a  valid 
consignee  DODAAC  during  incheck  by  either  a  PC  workstation  or 
hand-held  terminal,  CMOS  shall  frustrate  the  shipment  (status 
code  "FRE")  and  notify  the  ATSA  to  either  modify  the  shipment 
consignee  DODAAC  or  update  the  CMOS  consignee  information. 

1.6. 3. 2  Probable  bay  location.  During  incheck  by  either  a 
PC  workstation  or  hand-held  terminal,  CMOS  shall  display  a 
probable  bay  location  for  each  item  inchecked.  A  separate 


bay  location  shall  be  maintained  for  general,  MICAP,  999, 
personal  baggage,  household  goods,  and  special  handling 
shipments.  The  inchecker  shall  be  able  to  accept  or  override 
the  probable  bay  location. 

1 . 6 . 3 . 3  Probable  onward  movement  mode .  During  incheck  by 
either  a  PC  workstation  or  hand-held  terminal,  CMOS  shall 
display  the  probable  onward  movement  mode  for  the  shipment. 
This  capability  shall  support  all  mode  codes  in  DOD 

4500. 32-R.  The  inchecker  shall  be  able  to  accept  or  override 
the  probable  mode  code.  Either  of  these  actions  shall  update 
the  TCMD  information  for  the  shipment.  For  originating 
cargo,  the  probable  onward  movement  mode  shall  appear  on  the 
input  screen  for  mode  selection  in  Shipment  Planning. 

1 . 6 . 3 . 4  Reoriginate  cargo .  Based  on  the  onward  movement 
mode  code,  CMOS  shall  reoriginate  intransit  cargo  in  the 
surface  or  air  freight  terminal,  as  appropriate. 

1.6.4  Cargo  release  procedures .  CMOS  shall  provide  the 
capability  to  release  material  to  the  consignee  during  the 
incheck  procedure  using  either  the  PC  workstation  or 
hand-held  terminal.  The  name  and  organization  of  the 
recipient  shall  be  recorded  for  each  piece  released.  If  a 
signature  is  required,  CMOS  shall  provide  the  capability  to 
identify  all  or  selected  items  on  a  manifest,  and  produce  a 
listing  for  the  cargo  recipient  to  sign.  Upon  entry  into 
CMOS  of  the  recipient's  name  and  organization,  all  records  on 
this  list  shall  be  updated  and  annotated  that  a  signed 
transfer  document  is  on  file. 

1.6.5  MAC  i..,st  update  for  outbound  surface.  At  aerial 
ports,  CMOS  shall  automatically  prepare  and  electronically 
transmit  a  lifted  manifest  transaction  to  the  HQ  MAC  Host 
when  the  aerial  port  releases  the  cargo  for  onward  surface 
movement . 

1.6.6  Over/short  shipments.  At  aerial  port  locations,  CMOS 
shall  manage  over/short  shipments  for  MILSTAMP  .node  code  "F" 
cargo  in  the  following  manner: 

1.6. 6.1  Over  shipments  received  at  intended  destination. 

1.6. 6. 1.1  Over  shipment  on-hand.  At  the  receiving  station, 
an  over  shipment  shall  be  checked  against  the  over/short 
register  to  see  if  the  shipment  was  identified  earlier  as  a 
short  shipment.  If  not,  the  shipment  shall  be  added  to  the 
over  shipment  register.  The  system  manager  shall  be  notified 
of  the  over  shipment,  the  identity  of  the  origin  station,  and 
the  identities  of  enroute  stations.  The  system  manager  shall 


be  able  to  select  stations  that  could  have  been  responsible 
for  the  overage.  CMOS  shall  generate  an  over  shipment 
message  to  each  of  these  stations. 

1.6. 6. 1.2  Over  shipment  message  response.  Upon  receipt  of 
an  over  shipment  message,  the  origin  and  enroute  station  CMOS 
shall  determine  automatically  if  the  shipment  was  ever  at 
that  station. 

1.6. 6. 1.2.1  Over  shipment  not  handled.  If  no  record  exists, 
the  origin  or  enroute  station  CMOS  shall  electronically 
advise  the  requesting  CMOS  that  the  shipment  was  not  handled. 

1.6. 6. 1.2. 2  Over  shipment  handled;  onward  movement 
unrecorded.  If  a  record  exists  with  no  outbound  mission 
data,  the  origin  or  enroute  station  CMOS  shall  automatically 
generate  a  "dummy"  manifest  using  the  mission  number  from  the 
over  shipment  message  and  the  next  available  manifest  number. 
This  "dummy"  manifest  shall  be  automatically  sent  to  the  MAC 
Host  and  destination  station.  At  the  destination,  it  shall 
clear  the  item  from  the  over/short  shipment  register. 

1 . 6 . 6 . 1 . 2 . 3  Over  shipment  handled;  onward  movement  recorded . 
If  a  record  exists  with  outbound  mission  data,  the  origin  or 
enroute  station  CMOS  shall  automatically  send  a  message 
containing  the  outbound  mission  information  to  the  CMOS 
generating  the  over  shipment  message.  Upon  receipt,  this 
message  shall  cause  the  over  shipment  to  be  flagged  pending 
arrival  of  the  mission. 

1 . 6 . 6 . 2  Over  shipments  received  at  other  than  the  intended 
destination. 

1.6. 6. 2.1  Over  shipment  on-hand.  At  the  receiving  station, 
an  over  shipment  shall  be  checked  against  the  over/short 
register  to  see  if  the  shipment  was  identified  earlier  as  a 
short  shipment.  If  not,  the  shipment  shall  be  added  to  the 
over  shipment  register.  The  system  manager  shall  be  notified 
of  the  over  shipment,  the  identity  of  the  origin  station,  and 
the  identities  of  enroute  stations.  The  system  manager  shall 
be  able  to  select  stations  that  could  have  been  responsible 
for  the  overage.  CMOS  shall  generate  an  over  shipment 
message  to  each  of  these  stations. 

1.6. 6. 2. 2  Over  shipment  message  response.  Upon  receipt  of 
an  over  shipment  message,  the  origin  and  enroute  origin 
station  CMOS  shall  determine  automatically  if  the  shipment 
was  ever  at  that  station. 

1.6. 6. 2. 2.1  Over  shipment  not  handled.  If  no  record  exists, 
the  origin  or  enroute  station  CMOS  shall  electronically 
advise  the  requesting  CMOS  that  the  shipment  was  not  handled. 
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1.6. 6. 2. 2. 2  Over  shipment  handled;  onward  movement 
unrecorded.  If  a  record  exists  with  no  outbound  mission 
data,  the  origin  or  enroute  station  CMOS  shall  automatically 
generate  a  "dummy"  manifest  using  the  mission  number  from  the 
over  shipment  message  and  the  next  available  manifest  number. 
This  "dummy"  manifest  shall  be  automatically  sent  to  the  MAC 
Host  and  destination  station.  At  the  destination,  it  shall 
clear  the  item  from  the  over/short  shipment  register  and 
reoriginate  the  shipment  for  onward  movement. 

1 . 6 . 6 . 2 . 2 . 3  Over  shipment  handled;  onward  movement  recorded . 
If  a  record  exists  with  outbound  mission  data,  the  origin  or 
enroute  station  CMOS  shall  automatically  send  a  message 
containing  the  outbound  mission  information  to  the  CMOS 
generating  the  over  shipment  message.  Upon  receipt,  this 
message  shall  cause  the  TAC  for  the  over  shipped  item  to  be 
modified  ("S"  in  the  2nd  position)  and  the  item  to  be 
reoriginated  for  shipment  to  the  intended  destination.  Upon 
arrival  at  the  intended  destination,  the  TAC  shall  be 
returned  to  its  original  (premodification)  composition. 

1 . 6 . 6 . 3  Short  shipments . 

1.6. 6. 3.1  Short  shipment  record  on-hand  without  cargo.  At 
the  intended  destination,  a  short  shipment  shall  be  checked 
against  the  over/short  register  to  see  if  the  shipment  was 
identified  earlier  as  an  over  shipment.  If  not,  the  shipment 
shall  be  added  to  the  short  shipment  register.  The  system 
manager  shall  be  notified  of  the  short  shipment,  the  identity 
of  the  origin  station,  and  the  identities  of  enroute 
stations.  The  system  manager  shall  be  able  to  select  stations 
that  could  have  been  responsible  for  the  shortage.  CMOS 
shall  generate  a  short  shipment  message  to  each  of  these 
stations . 

1.6. 6. 3. 2  Short  shipment  message  response.  Upon  receipt  of 
an  short  shipment  message,  the  origin  and  enroute  station 
CMOS  shall  determine  automatically  if  the  shipment  was  ever 
at  that  station. 

1.6. 6. 3. 2.1  Short  shipment  not  handled.  If  no  record 
exists,  the  origin  or  enroute  station  CMOS  shall 
electronically  advise  the  requesting  CMOS  that  the  shipment 
was  not  handled. 

1.6. 6. 3. 2. 2  Short  shipment  located;  on-hand.  If  the  cargo 
is  at  a  station,  that  station  shall  reoriginate  the  shipment 
and  modify  the  TAC  ("S"  in  the  2nd  position)  for  the  item. 

In  addition,  it  shall  electronically  notify  the  CMOS 
generating  the  short  shipment  message  that  it  has  the  cargo. 
Upon  receipt,  this  message  shall  cause  v/ne  short  shipment  to 
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be  flagged  pending  receipt  of  the  cargo.  Upon  arrival  of  the 
cargo  at  the  intended  destination,  the  TAC  shall  be  returned 
to  its  original  (pre-modification)  composition.  For 
shipments  not  received  within  72  hours  of  being  flagged,  CMOS 
shall  automatically  transmit  a  follow-up  message  to  the 
station  that  reported  the  cargo  on  hand. 

1 . 6 . 6 . 3 . 2 . 3  Short  shipment  handled ;  onward  movement 
recorded.  If  the  cargo  has  been  shipped,  the  origin  or 
enroute  station  CMOS  shall  send  a  message  with  mission 
information  to  the  CMOS  generating  the  short  shipment 
message.  Upon  receipt,  this  message  shall  cause  the  short 
shipment  record  to  be  flagged  pending  arrival  of  the  mission. 
If  the  cargo  is  not  received  within  manifest  ETA  plus  24 
hours,  CMOS  shall  automatically  transmit  a  follow-up  message 
to  the  station  that  reported  the  cargo  on  hand.  If  an  abort 
manifest  transaction  is  received  for  the  mission  on  which  the 
previously  shorted  piece  was  scheduled  to  arrive,  CMOS  shall 
retransmit  a  short  shipment  message  to  the  station  which 
reported  the  mission  information. 

1.6. 6. 4  Unresolved  short  shipments.  If  the  short  shipment 
is  not  resolved  in  21  days  CMOS  shall  notify  the  system 
manager  to  manually  prepare  an  SF  361.  CMOS  shall  provide  a 
history  of  system  messages  (outbound  and  inbound)  associated 
with  locating  the  short  shipment.  CMOS  shall  not  remove 
items  from  the  short  shipment  register  unless  the  short 
shipment  has  been  resolved  or  SF  361  data  is  entered. 

1.6. 6. 5  System  manager  review.  CMOS  shall  provide  the 
system  manager  the  capability  to  review  the  over/short 
shipment  register,  the  status  of  items  in  the  register,  and 
the  inbound  over/short  messages  received  with  associated 
responses . 

1.7  Special  Handling.  At  an  aerial  port,  the  special 
handling  section  has  unique  requirements  because  it  is 
responsible  for  the  incheck,  storage,  and  onward  movement  of 
all  cargo  having  selected  air  commodity  and  special  handling 
codes  and  MAC  MICAP.  CMOS  shall  provide  special  handling  the 
capability  to  perform. all  the  functions  of  inbound  air  and 
surface  freight  and  the  incheck, 

palletization/containerization,  inventory,  and  TCMD 
modification  capabilities  of  outbound  air  and  surface 
freight.  This  capability  shall  include  only  cargo  with  the 
selected  air  commodity  and  special  handling  codes  and  MAC 
MICAP . 

1.8  Outbound  Air.  The  capabilities  described  in  this 
section  shall  be  added  to  the  7iir  Freight  capability  defined 
in  the  Specifications  for  CMOS  Increments  I  and  II. 
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1.8.1  Identify  palletization  requirements.  CMOS  shall 
provide  the  load  planner  with  the  capability  to  identify 
cargo  requiring  palletization  by  air  freight. 

1.8.2  Pallet  buildup.  CMOS  shall  provide  the  capability  to 
build  a  pallet.  This  shall  be  done  in  three  stages: 
creation  of  a  pallet  header  shell,  adding  of  items  to  the 
pallet,  and  capping  the  pallet.  When  the  pallet  is  capped, 
CMOS  shall  compute  the  document  weight  for  the  pallet.  No 
record  changes  can  be  accomplished  on  a  capped  pallet.  The 
operator  shall-  be  able  to  assign  a  grid  location  for  the 

' capped '  pallet . 

1.8.3  Pallet  weight  verification.  CMOS  shall  provide  the 
capability  to  enter  the  actual  weight  of  a  capped  pallet,  and 
automatically  compare  the  scale  weight  with  the  document 
weight.  If  the  differential  between  the  weights  is  out  of 
the  range  identified  in  MACR  76-1,  the  system  shall  change 
the  status  of  the  pallet  to  not  movement  ready,  notify  the  PC 
operator  of  the  status  change,  and  provide  the  capability  to 
review  the  pallet  contents. 

1.8.4  Load  planning  schematic.  CMOS  shall  support  load 
planning  by  providing  the  capability  to  produce  a  "pull 
sheet"  and  "load  sequence"  or  a  load  planning  schematic  for  a 
mission.  After  approval  by  the  load  planner,  the  schematic 
shall  be  made  available  to  air  freight. 

1.8.5  Management  Action  Indicator  (MAI).  CMOS  shall  use 
MAIs  to  display  cargo  backlogs  and  load  planning  lists .  MAIs 
shall  be  established  and  maintained  by  outbound  air  freight. 
MAIs  identify  the  intransit  destination  for  cargo  moving  to 
selected  final  destinations  via  selected  channels.  (e.g. 
Dover  AFB  would  have  an  MAI  (Travis  AFB)  for  all  cargo  moving 
to  consignees  in  the  far  east.  When  the  load  planner  looked 
at  his  cargo  backlog  for  Travis,  he  would  see  not  only  cargo 
with  Travis  as  the  ultimate  consignee,  but  any  cargo  having 
to  go  to  Travis  for  onward  movement  to  its  ultimate 
destination . ) 

1.8.6  Multiple  manifests.  CMOS  shall  provide  the  capability 
to  prepare  multiple  air  manifests  for  the  same  mission. 

1.9  Outbound  Surface.  The  capabilities  described  in  this 
section  shall  be  added  to  the  Surface  Freight  capability 
defined  in  the  Specifications  for  CMOS  Increments  I  and  II. 

1.9.1  Bay  location  changes  for  organic  military  air.  At  the 
aerial  port,  CMOS  shall  provide  the  capability  to  notify  the 
outbound  surface  freight  operator  that  the  ATSA  has  selected 
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surface  outbound  cargo  for  onward  movement  via  organic 
military  air.  This  notification  shall  direct  the  cargo  be 
moved  to  a  new  bay  location. 

1.9.2  Multiple  military  truck  destinations.  CMOS  shall 
provide  the  capability  to  manifest  trucks  to  multiple 
destinations.  Manifest  reference  numbers  shall  be  assigned 
for  each  destination. 

1.10  Miscellaneous  Reports.  HQ  MAC  shall  identify 
pre-formatted  reports  and  standard  queries  that  shall  be 
required . 
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